home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19960425-19960715 / 000372_news@columbia.edu _Fri Jul 5 05:25:22 1996.msg < prev    next >
Internet Message Format  |  2020-01-01  |  3KB
  1. Return-Path: news@columbia.edu
  2. Received: from apakabar.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30]) by watsun.cc.columbia.edu (8.7.5/8.7.3) with ESMTP id FAA07750 for <kermit.misc@watsun.cc.columbia.edu>; Fri, 5 Jul 1996 05:25:21 -0400 (EDT)
  3. Received: (from news@localhost) by apakabar.cc.columbia.edu (8.7.5/8.7.3) id FAA26375 for kermit.misc@watsun; Fri, 5 Jul 1996 05:25:18 -0400 (EDT)
  4. From: jrd@cc.usu.edu (Joe Doupnik)
  5. Newsgroups: comp.protocols.kermit.misc
  6. Subject: Re: file transfer
  7. Message-ID: <1996Jul4.223259.82354@cc.usu.edu>
  8. Date: 4 Jul 96 22:32:59 MDT
  9. References: <omafxh7spj.fsf@tees.cs.ualberta.ca> <omn31h57zl.fsf@tees.cs.ualberta.ca>
  10. Organization: Utah State University
  11. Lines: 29
  12. Path: news.columbia.edu!panix!imci5!pull-feed.internetmci.com!news.provo.novell.com!news.cs.utah.edu!cc.usu.edu!jrd
  13.  
  14. In article <omn31h57zl.fsf@tees.cs.ualberta.ca>, Vladimir Alexiev <vladimir@cs.ualberta.ca> writes:
  15. > A bit more on the same topic: I did some more testing, and here's what I
  16. > found.
  17. > - packet sizes up to 7000 are sustainable
  18. > - size 7500 causes kermit to drop to 3000, and then quickly climb back to
  19. >   7500. 
  20. > - size 9000 causes kermit to drop all the way down to 17 and climb back
  21. >   slowly. 
  22. > There certainly is a PhD on dynamic systems hidden somewhere here :-)
  23. > So I'll just stick with 7000, the overhead there is about 7% which is good
  24. > enough :-)
  25. ------------
  26.     Even overwhelming has degrees of excess. Far too many bytes can
  27. create a situation where the sending program encounters a rapid succession
  28. of error returns, all from the same set of packets because the fault hasn't
  29. gone away by the time more queued bytes want to hit the wire (it's trying too
  30. hard, *we* know that but the program doesn't). Once the first overload occurs
  31. and more bytes are still ready to go then errors can just keep happening and
  32. happening, and the rubber packet "halve on error" mechanism quickly results 
  33. in tiny packets.
  34.     I guess C Kermit needs to be more whimpy on transmission errors, but
  35. the difficulty is knowing when to stop waiting around and start transmitting
  36. again. The external devices (modems in this case) often don't give Kermit
  37. a hint on that matter.
  38.     MS-DOS Kermit is in control of the serial port hardware and thus has
  39. more sensitivity to low level troubles and knows how to back away gracefully.
  40. C Kermit is isolated by the operating system, and it can be trapped into
  41. these overload situations more easily.
  42.     Joe D.